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Abstract 


This document specifies how a Web Real-Time Communication (WebRTC) data channel can be 
used as a transport mechanism for the Message Session Relay Protocol (MSRP) and how the 
Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data 
channel, referred to as an MSRP data channel. Two network configurations are supported: the 
connection of two MSRP data channel endpoints; and a gateway configuration, which connects 
an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS. This 
document updates RFC 4975. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8873. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
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with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 


provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for transmitting a series of 
related instant messages in the context of a session. In addition to instant messaging, MSRP can 
also be used for image sharing or file transfer. MSRP was initially defined in [RFC4975] to work 
over TCP and TLS connections, and over a WebSocket subprotocol specified by [RFC7977]. 


This document specifies how a Web Real-Time Communication (WebRTC) data channel [RFC8831] 
can be used as a transport mechanism for MSRP without the TCP and TLS layers, and how the 
Session Description Protocol (SDP) offer/answer mechanism for data channels [RFC8864] can be 
used to negotiate such a data channel. 


In this document, an MSRP data channel refers to a WebRTC data channel for which the 
instantiated subprotocol is "msrp" and the data channel is negotiated using the SDP offer/answer 
mechanism [RFC8864]. 


Defining MSRP as a data channel subprotocol has many benefits: 


e provides to applications a proven protocol enabling instant messaging, file transfer, image 
sharing 

e integrates those features with other WebRTC voice, video, and data features 

e leverages the SDP-based negotiation already defined for MSRP 

e allows the interworking with MSRP endpoints running on a TCP or TLS connection 


Compared to the WebSocket protocol, which provides a message-passing protocol to applications 
with no direct access to TCP or TLS sockets, data channels provide a low-latency transport and 
leverage NAT-aware connectivity and the security features of WebRTC. 


This document defines an MSRP data channel endpoint as an MSRP application that uses a 
WebRTC data channel for MSRP transport. This document describes configurations for 
connecting such endpoint to another MSRP data channel endpoint, or to an MSRP endpoint that 
uses either TCP or TLS transport. 


This document updates [RFC4975] as described in Section 7. 
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2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. WebRTC Data Channel Considerations 


3.1. MSRP Data Channel 

The following WebRTC data channel property values [RFC8831] apply to an MSRP data channel: 
Property Value 
Subprotocol Identifier msrp 


Transmission reliability reliable 


Transmission order in-order 
Label See Section 4.3 
Table 1 


4. SDP Considerations 


The generic SDP considerations, including the SDP offer/answer procedures [RFC3264], for 
negotiating a WebRTC data channel are defined in [RFC8864]. This section and its subsections 
define the SDP considerations that are specific to an MSRP data channel, identified by the 
"subprotocol" attribute parameter, with an "msrp" parameter value in the 'dcmap' attribute. 


4.1. MSRP URI 


This document extends the MSRP URI syntax [RFC4975] by defining the new transport parameter 
value "dc" (an abbreviation of data channel): 


transport /= "dc" 
; Add "dc" to existing transports per Section 9 of [RFC4975] 


MSRP design provides for new transport bindings (see Section 6 of [RFC4975]). MSRP 
implementations are expected to allow unrecognized transports for which there is no need to 
establish a connection to the resource described by the URI, as is the case of data channels 
(Section 4.4). 
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4.2. MSRP URI msrp-scheme 


The msrp-scheme portion of the MSRP URI that represents an MSRP data channel endpoint (used 
in the SDP 'path' attribute and in the MSRP message headers) is always "msrps", which indicates 
that the MSRP data channel is always secured using DTLS as described in [RFC8831]. 


4.3. Use of the 'dcmap' Attribute 


An offerer and answerer SHALL, in each offer and answer, include a 'dcmap' attribute [RFC8864] 
in the SDP media description ("m=" section) [RFC4566] describing the SCTP association [RFC4960] 
used to realize the MSRP data channel. 


The attribute includes the following data channel parameters: 


e "label=" labelstring 


e "subprotocol=" "msrp" 


The labelstring is set by the MSRP application according to [RFC8864]. 


The offerer and answerer SHALL NOT include the "max-retr" and the "max-time" attribute 
parameters in the 'dcmap' attribute. 


The offerer and answerer MAY include the "ordered" attribute parameter in the 'dcmap' 
attribute. If included, the attribute parameter value SHALL be set to "true". 


Below is an example of a 'dcmap' attribute for an MSRP session to be negotiated with the "dcmap- 
stream-id" parameter set to 2 and the "label" parameter set to "chat": 


a=dcmap:2 label="chat";subprotocol="msrp" 


4.4. Use of the 'dcsa' Attribute 


An offerer and answerer can, in each offer and answer, include one or more data channel 
subprotocol attributes (‘dcsa' attributes) [RFC8864] in the "m=" section describing the SCTP 
association used to realize the MSRP data channel. An SDP attribute included in a 'dcsa' attribute 
is referred to as a DCSA-embedded attribute. 


If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute for which 
usage has not been defined for an MSRP data channel, the offerer or answerer should ignore the 
‘dcsa' attribute, following the rules in Section 6.7 of [RFC8864]. 


An offerer and answerer SHALL include a ‘dcsa' attribute for each of the following MSRP-specific 
SDP attributes: 


* defined in [RFC4975]: ‘path’. 
e defined in [RFC6714]: 'msrp-cema’. 
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e defined in [RFC6135]: 'setup’. See Section 4.5. 


It is considered a protocol error if one or more of the DCSA-embedded attributes listed above are 
not included in an offer or answer. 


An offerer and answerer MAY include a 'dcsa' attribute for any of the following MSRP-specific 
SDP attributes, following the procedures defined for each attribute: 


e defined in [RFC4975]: 'accept-types', 'accept-wrapped-types', and 'max-size’. 
e defined in [RFC4566]: 'sendonly’, 'recvonly’, ‘inactive’, and 'sendrecv'. 
e defined in [RFC5547]: all the parameters related to MSRP file transfer. See Section 4.7. 


A subsequent offer or answer MAY update the previously negotiated MSRP subprotocol attributes 
while keeping the 'dcmap' attribute associated with the MSRP data channel unchanged. The 
semantics for newly negotiated MSRP subprotocol attributes are per [RFC4975]. 


When MSRP messages are transported on a data channel, the 'path' attribute is not used for the 
routing of the messages. The MSRP data channel is established using the SDP offer/answer 
procedures defined in [RFC8864], and the MSRP messages are then transported on that data 
channel. This is different from legacy MSRP [RFC4975] but similar to MSRP Connection 
Establishment for Media Anchoring (MSRP CEMA) [RFC6714]. Because of this, a DCSA-embedded 
‘msrp-cema' attribute is mandated for MSRP sessions over data channels. However, when an 
endpoint receives an MSRP message over a data channel, it MUST still perform the MSRP URI 
comparison procedures defined in [RFC4975]. 


4.5. Use of the DCSA-Embedded 'setup' Attribute 


As described in Section 4.4, the usage of a DCSA-embedded 'setup' attribute is mandated for 
MSRP sessions over data channels. It is used to negotiate which MSRP data channel endpoint 
assumes the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no 
relationship with the DTLS connection establishment roles [RFC8841]. 


The DCSA-embedded 'setup' attribute is of the form "a=dcsa:x setup:<role>", with x being the data 
channel's SCTP stream identifier, so that the 'setup' attribute is explicitly associated with an 
MSRP session over a specific data channel. 


4.6. Session Closing 


An MSRP session is closed by closing the associated data channel following the procedures in 
[RFC8864]. 


The port value for the "m=" line SHOULD NOT be changed (e.g., to zero) when closing an MSRP 
session (unless all data channels are being closed and the SCTP association is no longer needed) 
since this would close the SCTP association and impact all of the data channels. In all cases in 
[RFC4975] where the procedure calls for setting the port to zero in the MSRP "m=" line in an SDP 
offer for TCP transport, the SDP offerer of an MSRP session with data channel transport SHALL 
remove the corresponding 'dcmap' and ‘dcsa' attributes. 


Recio & Holmberg Standards Track Page 6 


RFC 8873 MSRP over Data Channels January 2021 


4.7. Support for MSRP File Transfer Function 


SDP attributes specified in [RFC5547] for a file transfer "m=" line are embedded as subprotocol- 
specific attributes using the syntax defined in [RFC8864]. 


4.8. Example 


Below is an example of an offer and an answer that include the attributes needed to establish 
two MSRP sessions: one for chat and one for file transfer. The example is derived froma 
combination of examples in [RFC4975] and [RFC5547]. 


Offer: 


m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 

c=IN IP6 2001:db8::3 

a=max-message-size :100000 

a=sctp-port: 5000 

a=setup:actpass 

a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:\ 
3F :82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD 

a=tls-id:4a756565cddef@01be82 

a=dcmap:@ label="chat";subprotocol="msrp" 

a=dcsa:@ msrp-cema 

a=dcsa:@ setup:active 

a=dcsa:@ accept-types:message/cpim text/plain 

a=dcsa:@ path:msrps://2001 :db8: :3:54111/si438dsaodes ;dc 

a=dcemap:2 label="file transfer" ;subprotocol="msrp" 


a=dcsa:2 sendonly 

a=dcsa:2 msrp-cema 

a=dcsa:2 setup:active 

a=dcsa:2 accept-types:message/cpim 

a=dcsa:2 accept-wrapped-types:* 

a=dcsa:2 path:msrps://2001 :db8: :3:54111/jshA7we;dc 

a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ 


size:1463440 hash:sha-256:7C:DF :3E:5D:49:6B:19:E5:12:AB:4A:AD:\ 
4A:B1:3F:82:3E:3B:54:12:02:5D:18:DF:49:6B:19:E5:7C:AB:B9:AD 
a=desa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 


a=dcesa:2 file-disposition:attachment 

a=dcesa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" 
a=dcesa:2 file-icon:cid:id2@bob.example.com 

a=desa:2 file-range:1-1463440 
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Answer: 


m=application 51444 UDP/DTLS/SCTP webrtc-datachannel 

c=IN IP6 IP6 2001:db8::1 

a=max-message-size :100000 

a=sctp-port:6000 

a=setup:passive 

a=fingerprint :SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:\ 
B1:3F :82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D 

a=tls-id:65cd4a7565debe82f100 

a=dcmap:@ label="chat";subprotocol="msrp" 

a=dcsa:@ msrp-cema 

a=dcsa:@ setup:passive 

a=dcsa:@ accept-types:message/cpim text/plain 

a=dcsa:@ path:msrps://2001 :db8::1:51444/di551fsaodes ;dc 

a=dcemap:2 label="file transfer" ;subprotocol="msrp" 


a=dcsa:2 recvonly 
a=dcsa:2 msrp-cema 
a=dcsa:2 setup:passive 


a=dcsa:2 accept-wrapped-types:* 

a=dcsa:2 path:msrps://2001 :db8: :1:51444/jksh7Bwc ; dc 

a=dcesa:2 file-selector:name:"picture1l.jpg" type:image/jpeg \ 
size:1463440 

a=desa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 

a=dcesa:2 file-range:1-1463440 


2 
2 
2 
a=dcsa:2 accept-types:message/cpim 
2 
2 
2 


Note that due to RFC formatting conventions, this document splits SDP content that exceeds 72 
characters across lines, marking this line folding with a backslash character. This backslash and 
its trailing CRLF and whitespace would not appear in actual SDP content. 


5. MSRP Considerations 


The procedures specified in [RFC4975] apply except when this document specifies otherwise. 
This section describes the MSRP considerations specific to an MSRP data channel. 


5.1. Session Mapping 


In this document, each MSRP session maps to one data channel exactly. 


5.2. Session Opening 


Section 4.5 describes how the active MSRP data channel endpoint role is negotiated. The active 
MSRP data channel endpoint uses the data channel established for this MSRP session by the 
generic data channel opening procedure defined in [RFC8864]. 


As soon as the WebRTC data channel is opened, the MSRP session is actually opened by the active 
MSRP data channel endpoint. In order to do this, the active MSRP data channel endpoint sends 
an MSRP SEND message (empty or not) to the peer (passive) MSRP data channel endpoint. 
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5.3. Session Closing 


The closure of an MSRP session SHALL be signaled via SDP following the requirements in Section 
4.6. 


If the data channel used to transport the MSRP session fails and is torn down, the MSRP data 
channel endpoints SHALL consider the MSRP session failed. An MSRP data channel endpoint 
MAY, based on local policy, try to negotiate a new MSRP data channel. 


5.4. Data Framing 


Each text-based MSRP message is sent on the corresponding data channel using standard MSRP 
framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a 
single SCTP user message. Therefore all sent MSRP chunks SHALL have lengths of less than or 
equal to the value of the peer's 'max-message-size' attribute [RFC8841] associated with the SCTP 
association. 


5.5. Data Sending, Receiving, and Reporting 


Data sending, receiving, and reporting procedures SHALL conform to [RFC4975]. 


5.6. Support for MSRP File Transfer Function 


[RFC5547] defines an end-to-end file transfer method based on MSRP and the SDP offer/answer 
mechanism. This file transfer method is also usable by MSRP data channel endpoints with the 
following considerations: 


e As an MSRP session maps to one data channel, a file transfer session maps also to one data 
channel. 


e SDP attributes are negotiated as specified in Section 4.7. 


e Once the file transfer is complete, the same data channel MAY be reused for another file 
transfer. 


6. Gateway Considerations 


This section describes the network configuration where one MSRP endpoint uses an MSRP data 
channel as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP 
transport, and the two MSRP endpoints interwork via a gateway. 


Specifically, a gateway can be configured to interwork an MSRP session over a data channel with 
a peer that does not support data channel transport in one of two ways. 


In one model, the gateway performs as an MSRP Back-to-Back User Agent (B2BUA) to interwork 
all the procedures as necessary between the endpoints. No further specification is needed for this 
model. 
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Alternately, the gateway can provide transport-level interworking between MSRP endpoints 
using different transport protocols. In accordance with Section 4.4, ‘path’ attributes SHALL NOT 
be used for transport-level interworking. 


When the gateway performs transport-level interworking between MSRP endpoints, all of the 
procedures in Section 4 and Section 5 apply to each peer, with the following additions: 


e The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards the non-data 
channel endpoint. 

e If the non-data channel endpoint does not support MSRP CEMA, transport-level interworking 
mode is not possible, and the gateway needs to act as an MSRP B2BUA. 

e The gateway SHALL NOT modify the 'path' attribute received from data channel or from non- 
data channel endpoints. 

e The gateway SHALL NOT modify the 'setup' value received from data channel or from non- 
data channel endpoints. 

e The endpoint establishing an MSRP session using data channel transport SHALL NOT request 
inclusion of any relays, although it MAY interoperate with a peer that signals the use of 
relays. 


7. Updates to RFC 4975 


This document updates [RFC4975] by allowing the usage of the "msrps" scheme when the 
underlying connection is protected with DTLS. 


8. Security Considerations 


MSRP traffic over data channels, including confidentiality, integrity, and source authentication, is 
secured as specified by [RFC8831]. However, [RFC4975] allows transport of MSRP traffic over 
nonsecured TCP connections and does not provide a mechanism to guarantee usage of TLS end to 
end. As described in [RFC4975], even if TLS is used between some hops, TCP might still be used 
between other hops. Operators need to establish proper policies in order to ensure that the MSRP 
traffic is protected between endpoints. 


[RFC5547] specifies security considerations related to the usage of MSRP for file transfer. 
[RFC7092] specifies security considerations related to B2BUAs. 


Note that the discussion in Section 14.5 of [RFC4975] on MSRP message attribution to remote 
identities applies to data channel transport. 


If the Session Initiation Protocol (SIP) [RFC3261] is used to implement the offer/answer 
transactions for establishing the MSRP data channel, the SIP security considerations specified in 
[RFC3261] apply. 
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9. IANA Considerations 


9.1. "msrps" URI scheme 


This document modifies the usage of the "msrps" URI scheme, registered by [RFC4975], by adding 
DTLS as a protected transport indicated by the URI scheme. 


A reference to RFC 8873 has been added to the URI scheme "msrps" in the "Uniform Resource 
Identifier (URI) Schemes" registry. 


9.2. Subprotocol Identifier "msrp" 


A reference to RFC 8873 has been added to the subprotocol identifier "msrp" in the "WebSocket 
Subprotocol Name Registry". 


9.3. SDP Attributes 


This document modifies the usage of a set of SDP attributes if any of those attributes is included 
in an SDP 'dcsa' attribute associated with an MSRP data channel. The modified usage of the SDP 
‘setup’ attribute is described in Section 4.5. The usage of the other SDP attributes is described in 
Section 4.4. 


*'accept-types' 

e 'accept-wrapped-types' 
e 'file-date' 

e 'file-disposition' 
e 'file-icon' 

e 'file-range' 

e 'file-selector' 

e 'file-transfer-id' 
e ‘inactive’ 

e 'max-size' 

e 'msrp-cema' 

e 'path' 

e 'recvonly' 

e 'sendonly' 

e 'sendrecv' 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'accept-types' 
attribute in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 
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Contact email: iesg@ietf.org 

Attribute name: accept-types 

Usage level: dcsa (msrp) 

Purpose: Contain the list of media types that the endpoint is willing to receive. 
Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'accept-wrapped- 
types' attribute in the Session Description Protocol (SDP) Parameters "att-field" subregistry as 
follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: accept-wrapped-types 

Usage level: dcsa (msrp) 

Purpose: Contain the list of media types that the endpoint is willing to receive in an 
MSRP message with multipart content. 

Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'file-date' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: file-date 

Usage level: dcsa (msrp) 

Purpose: Indicate one or more dates related to the file in an MSRP file transfer 
negotiation. 

Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'file-disposition' 
attribute in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: _ file-disposition 

Usage level: dcsa (msrp) 

Purpose: Provide a suggestion to the other endpoint about the intended disposition of 
the file in an MSRP file transfer negotiation. 

Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'file-icon' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 
Contact email: iesg@ietf.org 
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file-icon 

dcsa (msrp) 

Contain a pointer to a small preview icon representing the contents of the file 
in an MSRP file transfer negotiation. 

RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'file-range' attribute 
in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 


Reference: 


IESG 

iesg@ietf.org 

file-range 

dcsa (msrp) 

Contain the range of transferred octets of the file in an MSRP file transfer 
negotiation. 

RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP ‘file-selector' attribute 
in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 
Reference: 


IESG 

iesg@ietf.org 

file-selector 

dcsa (msrp) 

Indicate a file in an MSRP file transfer negotiation. 
RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP ‘file-transfer-id' 
attribute in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 


Reference: 


IESG 

iesg@ietf.org 

file-transfer-id 

dcsa (msrp) 

Indicate a unique identifier of the file transfer operation in an MSRP file 
transfer negotiation. 

RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'inactive' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
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IESG 
iesg@ietf.org 
inactive 

dcsa (msrp) 
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Purpose: Negotiate the direction of the media flow on an MSRP data channel. 
Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'max-size' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: max-size 

Usage level: dcsa (msrp) 

Purpose: Indicate the largest message an MSRP endpoint wishes to accept. 
Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'msrp-cema' attribute 
in the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: msrp-cema 

Usage level: dcsa (msrp) 

Purpose: Indicate that the routing of MSRP messages transported on a data channel is 
more similar to the MSRP CEMA mechanism than the legacy MSRP routing 
mechanism. 

Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'path' attribute in the 
Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: path 

Usage level: dcsa (msrp) 

Purpose: Indicate an endpoint, but not used for routing, as described in Section 4.4. 
Reference: RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'recvonly' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: IESG 

Contact email: iesg@ietf.org 

Attribute name: recvonly 

Usage level: dcsa (msrp) 

Purpose: Negotiate the direction of the media flow on an MSRP data channel. 
Reference: RFC 8873 
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The usage level "dcsa (msrp)" has been added to the registration of the SDP 'sendonly' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 
Reference: 


IESG 

iesg@ietf.org 

sendonly 

dcsa (msrp) 

Negotiate the direction of the media flow on an MSRP data channel. 
RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'setup' attribute in the 
"att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 


Reference: 


IESG 

iesg@ietf.org 

setup 

dcsa (msrp) 

Negotiate the active role of an MSRP session over a data channel as per 
Section 4.5. 

RFC 8873 


The usage level "dcsa (msrp)" has been added to the registration of the SDP 'sendrecv' attribute in 
the Session Description Protocol (SDP) Parameters "att-field" subregistry as follows: 


Contact name: 
Contact email: 
Attribute name: 
Usage level: 
Purpose: 
Reference: 


IESG 

iesg@ietf.org 

sendrecv 

dcsa (msrp) 

Negotiate the direction of the media flow on an MSRP data channel. 
RFC 8873 


10. References 


10.1. Normative References 


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, 


[RFC3264] 


Recio & Holmberg 


RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/ 
rfc2119>. 


Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session 
Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, 
<https://www.rfc-editor.org/info/rfc3264>. 


Standards Track Page 15 


RFC 8873 


[RFC4566] 


[RFC4960] 


[RFC4975] 


[RFC5547] 


[RFC6135] 


[RFC6714] 


[RFC7977] 


[RFC8174] 


[RFC8831] 


[RFC8841] 


[RFC8864] 


MSRP over Data Channels January 2021 


Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", 
RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/ 
rfc4566>. 


Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 
10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>. 


Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay 
Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https:// 
www.rfc-editor.org/info/rfc4975>. 


Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A 
Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File 
Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009, <https://www.rfc- 
editor.org/info/rfc5547>. 


Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message 
Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 
2011, <https://www.rfc-editor.org/info/rfc6135>. 


Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media 
Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, 
DOI 10.17487/RFC6714, August 2012, <https://www.rfc-editor.org/info/rfc6714>. 


Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., and R. Ravindranath, "The 
WebSocket Protocol as a Transport for the Message Session Relay Protocol 
(MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016, <https://www.rfc- 
editor.org/info/rfc7977>. 


Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 
14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/ 
rfc8174>. 


Jesup, R., Loreto, S., and M. Tiixen, "WebRTC Data Channels", RFC 8831, DOI 
10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>. 


Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description 
Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission 
Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport", RFC 
8841, DOI 10.17487/RFC8841, January 2021, <https://www.rfc-editor.org/info/ 
rfc8841>. 


Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data 
Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/ 
RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>. 


10.2. Informative References 


[RFC3261] 


Recio & Holmberg 


Standards Track Page 16 


RFC 8873 MSRP over Data Channels January 2021 


Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., 
Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 
10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. 


[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back- 
to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https:// 
www.rfc-editor.org/info/rfc7092>. 


Acknowledgments 


The authors wish to acknowledge the borrowing of ideas from another Internet-Draft by Peter 
Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Paul 
Kyzivat, Jonathan Lennox, Uwe Rauschenhbach, Albrecht Schwarz, and Keith Drage for their 
invaluable comments. 


Richard Ejzak, Keith Drage, and Juergen Stoetzer-Bradler contributed to an earlier draft version 
of this document before the draft was readopted. 


Julien Maisonneuve helped with the readoption of this document, and Maridi R. Makaraju (Raju) 
contributed valuable comments after the document was readopted. 


Authors' Addresses 


Jose M. Recio (EDITOR) 
Unaffiliated 
Email: jose@ch3m4.com 


Christer Holmberg 

Ericsson 

Hirsalantie 11 

FI-02420 Jorvas 

Finland 

Email: christer._holmberg@ericsson.com 


Recio & Holmberg Standards Track Page 17 


